アクセスキーで最小特権にする重要性を改めて考えてみよう

こんにちはカスタマーソリューション部のこーへいです！

皆さんはIAMベストプラクティスのドキュメントを読んだことはありますでしょうか。

上記のドキュメントはAWSを使用する方には是非読んでいただきたいのですが、今回はアクセスキーを使用する際の最小特権の重要性を考えていきたいです。

前提としてアクセスキーはなるべく使用しない

アクセスキーは漏洩のしやすさや永続的な認証情報である性質等から、セキュリティインシデントを発生させやすい原因となっています。

そのためCloudshell等の代替手段がある場合は、そちらの利用を推奨しています。

今回の仮定するアクセスキーを利用するケース

今回のアクセスキーを利用するケースとして、以下と仮定します。

• ローカル端末からファイルをバッチ処理として定期的にS3バケットにアップロードする
  • ローカル端末から直接AWSリソースにアクセスする必要性があるため、アクセスキーを使用
• アクセスキーからIAMロールにスイッチする
  • アクセスキーの権限は、IAMロールにスイッチする権限のみ
  • IAMロールの権限は、特定S3バケットにファイルをアップロードする権限のみ

大変、アクセスキーが漏洩してしまった

ある日アクセスキーが漏洩したことが発覚、今回のケースにおいてシステム運用者が最終的にされて欲しくない攻撃を以下と仮定します。

• 攻撃者によるS3バケットへのマルウェアファイルのアップロード
• 攻撃者によるS3バケットへ保存しているファイルの上書き目的でのアップロード

最小特権による第一の壁「スイッチ先のIAMロール名の把握」

大変なことにアクセスキーが漏洩してしまいましたが、第一の壁として「スイッチ先のIAMロール名の把握」が立ち塞がります。

今回のケースではシステム運用者が想定する攻撃者の最終目標はS3へのファイルアップロードです。

しかしアクセスキーの権限は、IAMロールにスイッチする権限のみです。その為以下の操作ができません。

• IAMポリシーのRead権限がないため、手に入れたアクセスキーに付与されている権限を調べられない
  • 攻撃者目線では、このアクセスキーで何ができるのか分からない
• IAMRoleのRead権限がないため、スイッチ先のIAMロール名が分からない

上記により仮にアクセスキーが漏洩したとしても、最終的に攻撃者が「アクセスキーでIAMロールにスイッチする必要がある」「スイッチ先のIAMロール名の把握」の第一の壁を突破しない限り次の攻撃の準備に移行できません。

最小特権による第二の壁「S3バケット名の把握」

万が一第一の壁が突破されたとしても第二の壁「S3バケット名の把握」が立ち塞がります。

改めて、今回のケースではシステム運用者が想定する攻撃者の最終目標はS3へのファイルアップロードです。

しかしIAMロールの権限は、特定S3バケットにファイルをアップロードする権限のみです。その為以下の操作ができません。

• IAMポリシーのRead権限がないため、スイッチ先のIAMロールに付与されている権限を調べられない
  • 攻撃者目線では、このIAMロールで何ができるのか分からない
• S3バケットのRead権限がないため、攻撃対象のS3バケット名が分からない

上記により仮にIAMロールにスイッチされたとしても、最終的に攻撃者が「IAMロールにS3のファイルアップロード権限が付与されていることの把握」「S3バケット名の把握」の第二の壁を突破しない限り攻撃を行えません。

更に言えば、「攻撃者によるS3バケットへ保存しているファイルの上書き目的でのアップロード」に関してはS3に格納されているファイル名も特定する必要があるため、攻撃成功の難易度は更に高まります。

まとめ

権限を絞ることにより、攻撃を成功する難しさがイメージできたのではないでしょうか？

もしAdmin権限を付与していたアクセスキーが漏洩したのであれば、攻撃を成功させるための調査や攻撃先の対象がすぐにバレてしまい大変危険であることがわかります。

最小特権の重要性を改めて理解いただければと思います。